Nebula 2/Nebula Two.iso/SourceCode/MiscKit1.7.1/MiscKitArchive.mbox/mbox/[e-mail]_Fri Feb 4 15:02 MST 1994.msg

Internet Message Format | 1994-10-30 | 7KB

Received: from yvax.byu.edu by maine.et.byu.edu; Fri, 4 Feb 1994 15:02:02 -0700
Return-Path: <[e-mail]>
Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
 id <[e-mail]>; Fri, 4 Feb 1994 15:03:48 MST
Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-3 #4169)
 id <[e-mail]>; Fri, 4 Feb 1994 15:03:39 MST
Received: from acs1.byu.edu by alaska.et.byu.edu; Fri, 4 Feb 1994 15:03:21 -0700
Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
 id <[e-mail]>; Fri, 4 Feb 1994 15:02:03 MST
Received: from maine.et.byu.edu by yvax.byu.edu (PMDF V4.3-3 #4169)
 id <[e-mail]>; Fri, 4 Feb 1994 15:01:23 MST
Received: by maine.et.byu.edu; Fri, 4 Feb 1994 14:58:40 -0700
Date: Fri, 04 Feb 1994 14:58:40 -0700
From: [e-mail] (Don Yacktman)
Subject: Strings and other bad puns...
To: [e-mail]
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7BIT
Status: RO



And now, for yet another long rambling discourse, which,
if printed, would reach to the moon and back if you could
find paper strong enough to hold up under the forces which
would be applied on it if you tried to do that.  :-)

In the previous message, I say this:

> In the case of "file" objects
> we need to decide what exactly we want and who will do it.
> Any takers there?  (The one example sent to me is already
> duplicated by a lot of what is in the MiscString class...)

This brings up a very interesting point.  The MiscString class
is, frankly, huge.  All of what it does is useful in some
setting; that's why it is there.  But since it's been built
up in a very ad-hoc way, it's not as clean and "beautiful" as
it could be.  Honestly, if I were starting now, knowing what
I know now, I would have done some things quite differently.

Yeah, where this is leading is making heavy MiscString users
nervous, right?  You don't want me changing the whole thing
out from under you.  Well, I'm not suggesting that, exactly.

As many of you are aware, there is an organization, OPN, which
is at the moment trying to come up with a general, free, spec
for the bare minimum that a "string" class should implement.
This is to be a fully specified Obj-C protocol.  Now, at the
moment they are comparing various string class implementations
and will be compiling them into a (hopefully) well-designed
class, usin the best ideas from each.

One of the string classes they are evaluating is the MiscString.
I _hope_ to high heaven that the protocol they come up with
is much cleaner.  That said, I also fully intend to make sure
that the MiscString is in compliance with whatever they come
up with--it behooves us to do this.  What about the current
set of methods?  Well, here's what I envision happening:

(1) A new core string class, which only implements the basic
    string protocol as OPN defines it.

(2) Categories to implement any other protocols that OPN
    comes up with as standard interfaces for "optional"
    things that would be nice for a string class to do.

(3) A compatibility category for old MiscString methods.
    Any method that is replaced by the new OPN names will
    become part of the compatability category, which is a
    set of cover methods for the new stuff.

(4) The MOString and other compatability stuff is left in
    place as well.

It's possible to make a subclass of the core string to
implement the other functionality, but I am in more favor
of using categories there.  Since strings can be "understood"
in specific ways, but that may change over time, I don't
like having to take one string and -setStringValue: it a
different string class when the semantics change; I prefer
to just send the applicable message.  (Thus the MiscStringUNIX
is a category and not a subclass, for example.)

Anyway, my idea is that we advance the design to make it better,
but we don't break old code.  Now, for a few MiscKit versions
after the change the compatibility methods will be in the
default library.  In later releases, they will have to be
explicitly added to the library via a config file.  To aid
in switching over to the new methods, an optional -D cflag
will be available to print messages to the console that
will allow the user to make a list of "old" methods that were
called and suggest a replacement...which may be used to feed
a search-and-replace effort.  (I'd rather not make that an
automatic thing...you need to make sure you only replace the
pertinent method calls, not necessarily _every_ one...)

One other important thing to mention.  The test suite I am
currently writing will be modified and turned into the test
suite for validating the OPN protocol.  Until we know the
protocol, we don't know _how_ much it will need to be
changed, but I have given them permission to use the code
(any, all, some, or none) as thy see fit.  Hopefully that
test suite will be complete for the current MiscString by
Monday...and it's already found several MiscString bugs
for me.  Run it on the current version and you'll see a
few I haven't yet had time to fix!  (These are not bugs
that will ruin your app, for the most part, but are more
on boundary conditions that normally don't occur.  The
test suite is written to try and break every method by
sending it bad arguments of all sorts in addition to the
typical tests for proper function.)  This also means that
the current MiscString.rtf should be cleaned up completely
by Monday as well (I hope).

One quick question on the .rtf file:  it's now getting
rather huge--140k isn't exactly small.  I don't want to
break it up by protocol since it's nice to be able to
look through the method descriptions of all methods sorted
alphabetically, without having to know which category has
a particular method in it.  Should I break it up into
(1) the top level, and then (2) several method-description
files like A-M and N-Z?  Or would you prefer I just do it
as separate .rtf files for each of the categories?

Does this seem more or less along the right track?  As OPN
protocols become available, I wish to use them in the MiscKit
and be fully compliant to them.  That will make the MiscKit,
as a free kit, a least common denominator of sorts.  Commercial
kits should still exist...to go beyond what the MiscKit can
provide.  (For some, tech support is enough to warrant such
a purchase...)  Please note that I do _not_ consider the
MiscKit to be in direct competition with the commercial kits
but rather as something which encourages a certain higher
quality level from such kits.

Anyway, beyond these wild ramblings and crazy ideas, what
are your opinions?  Just because I see this as a good
possible future direction doesn't mean anything other than
that it is my opinion.  Where would you like to see it go?
What will be the most useful for you in the future?

Respond privately or to the list as you see fit...

Later,
-don